1. Field of the Invention
The present invention pertains to distributed component-based applications. More particularly, this invention relates to asymptotically configuring multiple application components into a predetermined state in a cost effective, error-proof, and time saving manner.
2. Description of the Related Art
A distributed application environment typically refers to an environment consisting of a number of independently operated computer systems coupled together by networks. The computer systems cooperate to provide computing resources for an application having a number of application components or elements running on the computer systems. Thus, a distributed application is a component-based application.
A component-based application may not necessarily have distributed application components. For example, the components of a component-based application may be co-located in or run by a single computer system. No matter whether the components are distributed or co-located, a component-based application typically depends on an explicit ordering for affecting its life-cycle operations (e.g., start-up, shutdown, etc.). The life-cycle operations are typically captured as scripts that contain explicit ordering. They are sometimes driven from detailed models that capture detailed dependencies.
In some cases, the scripts initiate a state transition on a component, test for completion of the notification (explicitly or implicitly) and then move on to the next step. This means that the scripts can move the application from one state to another by moving all of the components of the application from one state to the next state (i.e., state transition) in a sequential and centrally-controlled manner. In other cases, timed waits are employed for determining when to move onto the next step. The timed waits, however, take longer time than necessary which slow down the whole configuration process.
One disadvantage associated with using scripts is that the effect in either of the above situations is to serialize activities (i.e., sequential fashion), multiplying the total time for the state change as the number of components increases. Another disadvantage is that the scripts cause the state transition in a centrally-controlled manner because the scripts control when and how the state transition of a component is initiated and when the next step is performed. Another disadvantage is the dependency. The scripts have to receive the state transition completion notification of a component before moving onto the next step. These disadvantages become even more obvious as the number of application components increases.
One prior solution is to inject explicit parallelism into the scripts. This can significantly improve the speed of application state transitions. However, it also increases the complicity of the scripts, resulting in high implementation cost. This consequently increases the time of developing the scripts and the probability of errors in developing the scripts.
Another problem associated with the use of scripts (regardless of parallelism) is that the scripts typically deal poorly with error conditions. The error conditions may include failure of a component and improper state transition, etc. Since the actions or operations contained in the scripts are explicit, each potential error condition must be dealt with explicitly. As the size and complexity of the application increase, the complexity of these scripts tend to increase more rapidly (sometimes exponentially), greatly increasing the probability of an unrecoverable error. Consequently, the application becomes less resilient to partial failures even as the potential for partial failures increases.
When a state transition is initiated, the various components that make up the system will often need to fetch configuration information from repository (e.g., database) in order to act on the transaction. With a very large application (i.e., application having a very large number of components), these accesses are often either serialized or performed in parallel. The serialized accesses stretch the time needed to complete the entire transition. The parallel accesses tend to overload the repository, resulting in increased response time and potential timeout failures.
One feature of the present invention is to allow state transition of an application having a large number of application components.
Another feature of the present invention is to allow state and/or configuration change of an application having a large number of application components in a cost effective and time saving manner.
A further feature of the present invention is to allow state and/or configuration change of an application having a large number of application components regardless of any component failures or errors.
A still further feature of the present invention is to allow asymptotic and automatic state and/or configuration change of an application having a large number of application components.
A still further feature of the present invention is to use randomization in time and space or randomization in time and distribution in space to achieve balanced accesses to an information store by a large number of application components of an application.
A configuration system for an application having a plurality of application components is described. The configuration system includes a configuration oracle/initiator that repeatedly asserts a desired state to the application components to operate in that desired state. The desired state is a predetermined state. The configuration oracle only asserts the desired state to the application components and does not control the manner in which each of the application components moves to the desired state. The configuration system also includes a configuration engine in each of the application components that causes the corresponding application components to move to the desired state upon receiving the state assertion of the desired state unless the configuration engine determines that the corresponding application component is already in the desired state.
A method of configuring an application having a plurality of application components is also described. The method includes the step of repeatedly asserting a desired state to the application components to cause the application components to operate in the desired state from a configuration oracle/initiator. The configuration oracle, however, does not control the manner in which each of the application components moves to the desired state. The method further includes the step of using a configuration engine in each of the application components to cause the corresponding application components to move to the desired state upon receiving the asserted desired state unless the configuration engine determines that the corresponding application component is already in the desired state.
A method of balancing accesses to an information store by a plurality of application components of an application includes the step of providing a plurality of storage replicas for the information store. Each of the storage replicas stores the same set of data as the information store. The method also includes the step of generating a random delay (e.g., a bounded random delay) for each of the application components to access the information store. The method may also includes the step of randomly selecting one of the replicas for each of the application components such that none of the replicas is overwhelmed by the accesses from the application components. Alternatively, each of the application components is assigned exclusively to one of the replicas such that accesses to the information store are distributed in space.